Satellite links suffer from longer propagation delays compared to terrestrial links The delay can be as high as 500 ms round-trip for a geostationary satellite link. Most Internet traffic uses the Transmission Control Protocol (TCP), which is highly susceptible to the delay-bandwidth product and exhibits very poor performance in satellite channels.
To mitigate the negative effects of the satellite propagation delay on Internet traffic, commercial satellite networks usually implement a split-connection TCP Performance Enhancing Proxy (PEP). A PEP agent is installed at the satellite gateway between the satellite network and the Internet. The PEP agent inspects every TCP packet that flows through the network and sends back premature acknowledgments to the TCP senders. Studies have shown that this technique leads to significant performance improvement in satellite networks.
Commercial satellite networks also employ HTTP proxy servers, at the central hub and each client location, to improve the speed of response to web browsing requests for Internet traffic. When the remote client makes a request for a webpage, the web server responds with the requested base HTML page. The hub HTTP proxy server intercepts and reads the web page and sends multiple GET requests to the destination web server to retrieve all the embedded objects in the base page. This exchange occurs over a high-speed terrestrial connection between the hub and the Internet, thereby saving the time each request would have needed for a round trip over the satellite link. As the objects are retrieved by the hub, they are immediately forwarded to the client proxy. The client browser GET requests are terminated at the local proxy server, which forwards the pre-fetched documents to the client browser immediately. The net result is that only a single GET request from the user browser traverses the satellite link, while a set of rapid responses quickly deliver the requested webpage and associated elements to the browser.
Two protocols that are widely used for secure unicast communication are the Internet Security Protocol (IPSEC) and the Secure Socket Layer (SSL) protocol.
IPSEC creates an end-to-end secure channel at the network layer for the secure transfer of traffic between two end users. The problem with using IPSEC in satellite networks is that it disables the functionality of the PEPs. The IP packet payload, which includes the TCP header, is encrypted with keys known only to the end points. Therefore a TCP PEP, which is an intermediate node in the communication path, cannot read or modify the TCP header, since the PEP does not know the keys. Consequently the PEP cannot function, leading to a degradation in the performance of the TCP protocol.
The Secure Socket Layer (SSL), on the other hand, operates above the transport layer in the protocol stack and establishes a secure HTTP (HTTPS) session on a need basis. SSL encrypts the TCP payload (the application layer HTTP data) between the client and the server, but the TCP header is transmitted in the clear. Therefore the TCP PEPs can function correctly with SSL. However, the HTML webpage encrypted into SSL records are readable only by the client and the server who have the decryption keys. The keys are not available to the HTTP proxy, and therefore the HTTP proxy cannot read the HTML webpage. Consequently, HTML object pre-fetching by the hub proxy server cannot take place. The net result is that a web page with n−1 embedded objects takes n*RTT to get loaded, an increase in delay by a factor of n.